Deavmi's coding shack
Commit 9a8cf8ec781b1c5b99802896f2d049ca1b53522b
Parents : 7446889
Author : Tristan B. Kildaire <deavmi@disroot.org>
Date : 2021-08-11T17:27:30+02:00
Added 2 new journal entries
Changes
2 files changed, 110 insertions(+), 0 deletions(-)
Diff
diff --git a/new_docs/content/journal/deps.md b/new_docs/content/journal/deps.md
new file mode 100644
index 0000000..a931c8d
--- /dev/null
+++ b/new_docs/content/journal/deps.md
@@ -0,0 +1,72 @@
+---
+title: "Depoendency generation"
+date: 2021-08-11
+author: Tristan B. Kildaire
+tags: [typechecking, dependency, static, oop, tree]
+---
+
+## Working dependency generation (so far)
+
+Just a quick update. I have started, I'd say about two months ago maybe, working on the dependency tree generaiton and it is working. This tree
+represents the order of initialization of entities and when completed in its construction it will be used for code generation simply by
+traversing down the tree.
+
+Currently we parse the syntax tree generated by the parser and generate a new tree with components that contain a reflection or ressemblance rather
+to their syntactic counterpart but with more information, such as has the node been visited already etc.
+
+An example of this is done if you checkout to the commit `06dbf479ffdfdfa7b2f314a6f2860c75e16bb52f` on branch `typecheck_refactor` and run the following:
+
+```bash
+dub build --force
+./tlang compile source/tlang/testing/typecheck/basic_dependence_correct1.t
+```
+
+This will run on the source file below:
+
+```d
+module typeChecking1;
+
+A aInstance;
+B bInstance;
+int k;
+
+class A
+{
+ static int pStatic;
+ static B bInstanceStatic;
+ static A aInstanceStaticMoi;
+
+ int poes;
+}
+
+class B
+{
+ static int jStatic;
+ static A aInstanceStatic;
+}
+```
+
+And will output the following:
+
+```
+bruh
+ (S) typeChecking1.aInstance
+ typeChecking1.A
+ (S) typeChecking1.A.pStatic
+ (S) typeChecking1.A.bInstanceStatic
+ typeChecking1.B
+ (S) typeChecking1.B.jStatic
+ (S) typeChecking1.B.aInstanceStatic
+ (S) typeChecking1.A.aInstanceStaticMoi
+ (S) typeChecking1.bInstance
+ (S) typeChecking1.k
+```
+
+Which if we look at it shows the correct initialization of that code. We first init the module (implicit so far). Then we see that `aInstance` needs to be declared, so we init it, as it is `static`, but because it refers to a class type, `A`, we must statically initialize that class too (initilizing its `static` entities). So we init `typeChecking1.A` (our class), as you can see we then initialize the `pStatic`, which needs no further initlaization, then we do `bInstanceStatic`, this must init class B`, so we do that,
+but you see there would be a loop now, but because when we enter `A` for its static initlaization we set it as visited we know therefore it is busy initting and we should not re-init it (we are basically a dependency of it), then we init `jStatic` and return.
+
+As you can see there is not dependency on `bInstance` on class `B` as it would have already been initted, and `k` didn't require anything to be initted but itself.
+
+## More exmaples
+
+There is another more complex example ending in `2`, same test case directory.
\ No newline at end of file
diff --git a/new_docs/content/journal/deps_next.md b/new_docs/content/journal/deps_next.md
new file mode 100644
index 0000000..c9e170b
--- /dev/null
+++ b/new_docs/content/journal/deps_next.md
@@ -0,0 +1,38 @@
+---
+title: "Needing to add path-hopper"
+date: 2021-08-11
+author: Tristan B. Kildaire
+tags: [typechecking, dependency, static, oop, tree, paths, grandresolver]
+---
+
+## Path hopper
+
+The parser when it sees:
+
+```d
+int o = new A().l.p.p;
+```
+
+Will see a variable declaration for `o` of type `int` and then an atached _VariableAssignment_ with the expression, `new A().l.p.p` which is actually just 3 expressions. The outer layer is a _BinaryOperatorExpression_, with an _LHS_ of `new A()` and an _RHS_ of `l.p.p`. You might be thinking ae there not more bin-ops? Nope, the lexer returns `l.p.p` as one unit to the parser, it is seen simply as some _Entity_ (an object with a name). It is smart as to when to do this, it knows that a dot must be followed and in the case here we end the first expression with `.` as it was preceded by `new A()` (it's the `()` which set it off). Then the first dot splits this up, however we check backwards each step after encountering a dot, if what follows is not a dot valid for a path, say now a number out of nowhere (as the first character), then we produce tokens `new A()`, `.` and `1a` in an example such as:
+
+```d
+new A().13
+```
+
+However, if it was:
+
+```d
+new A().a12.a
+```
+
+Then we'd have the tokens `new A()`, `.`, `a12.`. So this is what we would want out of a lexer such that we can then easily get the proper parsing as such done, making sure
+the right _kinds_ (potentially) of entities follow (not yet typechecked).
+
+However, when we do dependency checking we must actually resolve this path (which we alreayd have a tool for, the *grand resolver*). But we must visit each hop, and do a dependency check depending on the type of thing it refers to.
+
+Infact we must do the following:
+
+1. Make sure each entity in the path (as we process each) exists *name-wise*
+2. Make sure we init along the way if possible and given the current context
+ 1. Context implies the `static` or `non-static` nature of what we are accessing (so more of a type-checking thing)
+ 2. Initialization means to init it, add it to the dependency tree
\ No newline at end of file
Served by rngit 1.5.0 - Generated in 0.08s